A distributed transaction may include a set of processes or operations that may involve the use of more than one network host/resource. For example, a distributed transaction may call for database updates or operations using more than one database. A network host may provide for transaction resources utilized by a process, such as the database that requires updating and/or use. A transaction manager may receive a distributed transaction and prepare participating processes to execute on required network hosts. Thus, the transaction manager may prepare a coordinator network host/node that manages a set of participating network nodes each executing one or more processes of the distributed transaction. When the participating network nodes are established, the participating network node may establish sub-coordinators that register with the upstream coordinator on the transaction manager. Participants executing the processes received by the participating network node may then register with the sub-coordinator instead of the coordinator on the transaction manager. Thus, the transaction manager may view the sub-coordinator as a participant, while each participant views the sub-coordinator as the main coordinator.
Similar to other transactions, distributed transaction must maintain atomicity, consistency, isolation, and durability properties (ACID properties). Atomicity requires that changes made during processing a transaction are atomic, either all the changes to a database during an operation or update occur or they all do not occur. This prevents database updates from partially occurring, which would affect the reliability and consistency of the databases. Thus, in the event of a system failure, if a sub-coordinator does not recover as quickly as a corresponding participant, the participant must wait until the sub-coordinator recovers to commit or rollback the process.